I know you took this from the other reaction model, but that one sets a bad example here. These lines should correspond as closely as possible to the folder structure and file name. This is not technically necessary, but a convention we follow to make them easy to remember:

If you make the constructor the default constructor then you usually do not need to implement it at all. Just remove it from here and from the header file.

Please put these functions at the end of the list of public functions here and in the source file. This is just a convention we (try to) follow, but it makes navigating the source files easier.
A typical class structure in ASPECT looks like this (with many functions being optional):

class ClassName
{
  constructor();

  initialize();

  all_other_minor_functions();

  main_function(in this case melt_fraction);

  declare_parameters();

  parse_parameters();

  private:

  ... all member variables and private functions
}

can be present or is present? I think you mean is present because can be present would be 100%?

there is no melt_fractions variable

Oh, is that really the meaning of q? We usually use q as an index for the quadrature point to index into the vectors that are contained inside in. Please clarify and if you use this variable for something else, maybe find a different name unless it has to be q for other reasons.

I think this comment here is redundant now. All of these parameters are from Tian et al since this is the Tian et al plugin.

All of these numbers are fixed and will never change during the program runtime. You can tell this to the compiler, which will then optimize the code further and also prevent you from accidentally changing the values by changing their type from std::vector<double> to constexpr std::array<double,N> where N is the number of values in this array. Initialization and access to these arrays can remain unchanged.

same here, make this a constexpr std::array

So you put the parameters of the Tian model in their own subsection now. However, this means the parameter files of everyone using the reactive fluid flow model with the 3.0 version will need to be updated. Please include a changelog entry that mentions this. Additionally, you could extend our update scripts in contrib/utilities/update_scripts/prm_files/ to automatically move this parameter. The closest operation that does something like this is probably this function. However, the update process looks a bit cryptic, I leave this up to you to decide if this is important enough.